Django-modellarv: Abstrakta basklasser vs. flertabellsarv

Djangos objektrelationella mappning (ORM) erbjuder kraftfulla funktioner för att modellera data och interagera med databaser. En av nyckelaspekterna för effektiv databasdesign i Django är att förstå och utnyttja modellarv. Detta gör att du kan återanvända gemensamma fält och beteenden över flera modeller, vilket minskar kodduplicering och förbättrar underhållbarheten. Django erbjuder två primära typer av modellarv: abstrakta basklasser och flertabellsarv. Varje tillvägagångssätt har sina egna användningsfall och konsekvenser för databasstruktur och prestanda vid förfrågningar. Denna artikel ger en omfattande genomgång av båda, och vägleder dig om när du ska använda varje typ och hur du implementerar dem effektivt.

Förståelse för modellarv

Modellarv är ett grundläggande koncept inom objektorienterad programmering som låter dig skapa nya klasser (modeller i Django) baserade på befintliga. Den nya klassen ärver attribut och metoder från föräldraklassen, vilket gör att du kan utöka eller specialisera förälderns beteende utan att skriva om kod. I Django används modellarv för att dela fält, metoder och meta-alternativ över flera modeller.

Att välja rätt typ av arv är avgörande för att bygga en välstrukturerad och effektiv databas. Felaktig användning av arv kan leda till prestandaproblem och komplexa databasscheman. Därför är det viktigt att förstå nyanserna i varje tillvägagångssätt.

Abstrakta basklasser

Vad är abstrakta basklasser?

Abstrakta basklasser är modeller som är utformade för att ärvas från, men som inte är avsedda att instansieras direkt. De fungerar som ritningar för andra modeller och definierar gemensamma fält och metoder som bör finnas i alla barnmodeller. I Django definierar du en abstrakt basklass genom att sätta abstract-attributet i modellens Meta-klass till True.

När en modell ärver från en abstrakt basklass kopierar Django alla fält och metoder som definierats i den abstrakta basklassen till barnmodellen. Den abstrakta basklassen själv skapas dock inte som en separat tabell i databasen. Detta är en viktig skillnad från flertabellsarv.

När ska man använda abstrakta basklasser

Abstrakta basklasser är idealiska när du har en uppsättning gemensamma fält som du vill inkludera i flera modeller, men du behöver inte göra förfrågningar direkt mot den abstrakta basklassen. Några vanliga användningsfall inkluderar:

• Tidsstämplade modeller: Lägga till fälten created_at och updated_at i flera modeller.
• Användarrelaterade modeller: Lägga till ett user-fält i modeller som är associerade med en specifik användare.
• Metadatamodeller: Lägga till fält som title, description och keywords för SEO-ändamål.

Exempel på en abstrakt basklass

Låt oss skapa ett exempel på en abstrakt basklass för tidsstämplade modeller:

            
from django.db import models

class TimeStampedModel(models.Model):
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)

    class Meta:
        abstract = True

class Article(TimeStampedModel):
    title = models.CharField(max_length=200)
    content = models.TextField()

    def __str__(self):
        return self.title

class Comment(TimeStampedModel):
    article = models.ForeignKey(Article, on_delete=models.CASCADE)
    text = models.TextField()

    def __str__(self):
        return self.text

            

              
                Copy
              
            
          

I det här exemplet är TimeStampedModel en abstrakt basklass med fälten created_at och updated_at. Både modellerna Article och Comment ärver från TimeStampedModel och får automatiskt dessa fält. När du kör python manage.py migrate kommer Django att skapa två tabeller, Article och Comment, var och en med fälten created_at och updated_at. Ingen tabell kommer att skapas för `TimeStampedModel` själv.

Fördelar med abstrakta basklasser

• Återanvändning av kod: Undviker duplicering av gemensamma fält och metoder över flera modeller.
• Förenklat databasschema: Minskar antalet tabeller i databasen, eftersom den abstrakta basklassen inte är en egen tabell.
• Förbättrad underhållbarhet: Ändringar i den abstrakta basklassen reflekteras automatiskt i alla barnmodeller.

Nackdelar med abstrakta basklasser

• Inga direkta förfrågningar: Du kan inte göra förfrågningar direkt mot den abstrakta basklassen. Du kan bara göra förfrågningar mot barnmodellerna.
• Begränsad polymorfism: Det är svårare att behandla instanser av olika barnmodeller enhetligt om du behöver komma åt gemensamma fält definierade i den abstrakta klassen genom en enda förfrågan. Du skulle behöva göra separata förfrågningar mot varje barnmodell.

Flertabellsarv

Vad är flertabellsarv?

Flertabellsarv är en typ av modellarv där varje modell i arvshierarkin har sin egen databastabell. När en modell ärver från en annan modell med hjälp av flertabellsarv skapar Django automatiskt en en-till-en-relation mellan barnmodellen och föräldramodellen. Detta gör att du kan komma åt fälten i både barn- och föräldramodellerna genom en enda instans av barnmodellen.

När ska man använda flertabellsarv

Flertabellsarv är lämpligt när du vill skapa specialiserade modeller som har en tydlig "är-en"-relation med en mer allmän modell. Några vanliga användningsfall inkluderar:

• Användarprofiler: Skapa specialiserade användarprofiler för olika typer av användare (t.ex. kunder, leverantörer, administratörer).
• Produkttyper: Skapa specialiserade produktmodeller för olika typer av produkter (t.ex. böcker, elektronik, kläder).
• Innehållstyper: Skapa specialiserade innehållsmodeller för olika typer av innehåll (t.ex. artiklar, blogginlägg, nyhetsartiklar).

Exempel på flertabellsarv

Låt oss skapa ett exempel på flertabellsarv för användarprofiler:

            
from django.db import models
from django.contrib.auth.models import User

class Customer(User):
    phone_number = models.CharField(max_length=20, blank=True)
    address = models.CharField(max_length=200, blank=True)

    def __str__(self):
        return self.username

class Vendor(User):
    company_name = models.CharField(max_length=100, blank=True)
    payment_terms = models.CharField(max_length=100, blank=True)

    def __str__(self):
        return self.username

            

              
                Copy
              
            
          

I det här exemplet ärver både Customer- och Vendor-modellerna från den inbyggda User-modellen. Django skapar tre tabeller: auth_user (för User-modellen), customer och vendor. Tabellen customer kommer att ha en en-till-en-relation (implicit en ForeignKey) med tabellen auth_user. På samma sätt kommer tabellen vendor att ha en en-till-en-relation med tabellen auth_user. Detta gör att du kan komma åt standardfälten i User (t.ex. username, email, password) genom instanser av Customer- och Vendor-modellerna.

Fördelar med flertabellsarv

• Tydlig "är-en"-relation: Representerar en tydlig hierarkisk relation mellan modeller.
• Polymorfism: Låter dig behandla instanser av olika barnmodeller som instanser av föräldramodellen. Du kan göra en förfrågan mot alla `User`-objekt och få resultat som inkluderar både `Customer`- och `Vendor`-instanser.
• Dataintegritet: Upprätthåller referensintegritet mellan barn- och föräldratabellerna genom en-till-en-relationen.

Nackdelar med flertabellsarv

• Ökad databaskomplexitet: Skapar fler tabeller i databasen, vilket kan öka komplexiteten och potentiellt sakta ner förfrågningar.
• Prestanda-overhead: Att göra förfrågningar mot data som spänner över flera tabeller kan vara mindre effektivt än att göra förfrågningar mot en enda tabell.
• Risk för redundant data: Om du inte är försiktig kan du råka lagra samma data i flera tabeller.

Proxy-modeller

Även om det inte strikt är en typ av modellarv på samma sätt som abstrakta basklasser och flertabellsarv, är proxy-modeller värda att nämna i detta sammanhang. En proxy-modell låter dig modifiera beteendet hos en modell utan att ändra dess databastabell. Du definierar en proxy-modell genom att sätta proxy = True i modellens Meta-klass.

När ska man använda proxy-modeller

Proxy-modeller är användbara när du vill:

• Lägga till anpassade metoder i en modell: Utan att ändra modellens fält eller relationer.
• Ändra standardordningen för en modell: För specifika vyer eller sammanhang.
• Hantera en modell med en annan Django-app: Samtidigt som den underliggande databastabellen behålls i den ursprungliga appen.

Exempel på en proxy-modell

            
from django.db import models

class Article(models.Model):
    title = models.CharField(max_length=200)
    content = models.TextField()
    published = models.BooleanField(default=False)

    def __str__(self):
        return self.title

class PublishedArticle(Article):
    class Meta:
        proxy = True
        ordering = ['-title']

    def get_absolute_url(self):
        return f'/articles/{self.pk}/'

            

              
                Copy
              
            
          

I det här exemplet är PublishedArticle en proxy-modell för Article. Den använder samma databastabell som Article men har en annan standardsortering (ordering = ['-title']) och lägger till en anpassad metod (get_absolute_url). Ingen ny tabell skapas.

Att välja rätt typ av arv

Följande tabell sammanfattar de viktigaste skillnaderna mellan abstrakta basklasser och flertabellsarv:

Här är en beslutsguide som hjälper dig att välja rätt typ av arv:

• Behöver du göra förfrågningar direkt mot basklassen? Om ja, använd flertabellsarv. Om nej, överväg abstrakta basklasser.
• Skapar du specialiserade modeller med en tydlig "är-en"-relation? Om ja, använd flertabellsarv.
• Behöver du främst dela gemensamma fält och metoder? Om ja, använd abstrakta basklasser.
• Är du oroad över databaskomplexitet och prestanda-overhead? Om ja, föredra abstrakta basklasser.

Bästa praxis för modellarv

Här är några bästa praxis att följa när du använder modellarv i Django:

• Håll arvshierarkier grunda: Djupa arvshierarkier kan bli svåra att förstå och underhålla. Begränsa antalet nivåer i din arvshierarki.
• Använd meningsfulla namn: Välj beskrivande namn för dina modeller och fält för att förbättra kodens läsbarhet.
• Dokumentera dina modeller: Lägg till docstrings i dina modeller för att förklara deras syfte och beteende.
• Testa dina modeller noggrant: Skriv enhetstester för att säkerställa att dina modeller beter sig som förväntat.
• Överväg att använda mixins: Mixins är klasser som tillhandahåller återanvändbar funktionalitet som kan läggas till i flera modeller. De kan vara ett bra alternativ till arv i vissa fall. En mixin är en klass som tillhandahåller funktionalitet som ska ärvas av andra klasser. Det är inte en basklass utan en modul som ger ett specifikt beteende. Du kan till exempel skapa en `LoggableMixin` för att automatiskt logga ändringar i en modell.
• Var medveten om databasprestanda: Använd verktyg som Django Debug Toolbar för att analysera prestanda för förfrågningar och identifiera potentiella flaskhalsar.
• Överväg databasnormalisering: Undvik att lagra samma data på flera ställen. Databasnormalisering är en teknik som används för att minska redundans och förbättra dataintegriteten genom att organisera data i tabeller på ett sådant sätt att databasens integritetsbegränsningar korrekt upprätthåller beroenden.

Praktiska exempel från hela världen

Här är några globala exempel som illustrerar användningen av modellarv i olika applikationer:

• E-handelsplattform (Global):
  • Flertabellsarv kan användas för att modellera olika typer av produkter (t.ex. PhysicalProduct, DigitalProduct, Service). Varje produkttyp kan ha sina egna specifika attribut samtidigt som de ärver gemensamma attribut som namn, beskrivning och pris från en bas-Product-modell. Detta är särskilt användbart för internationell e-handel, där produktvariationer på grund av regleringar eller logistik kräver distinkta modeller.
  • Abstrakta basklasser kan användas för att lägga till gemensamma fält som 'shipping_weight' och 'dimensions' för alla fysiska produkter, eller 'download_link' och 'file_size' för alla digitala produkter.
• Fastighetshanteringssystem (Internationellt):
  • Flertabellsarv kan modellera olika typer av fastigheter (t.ex. ResidentialProperty, CommercialProperty, Land). Varje typ kan ha unika fält som 'number_of_bedrooms' för bostadsfastigheter eller 'floor_area_ratio' för kommersiella fastigheter, samtidigt som de ärver gemensamma fält som 'address' och 'price' från en bas-Property-modell.
  • Abstrakta basklasser kan lägga till gemensamma fält som 'listing_date' och 'available_date' för att spåra fastighetens tillgänglighet.
• Utbildningsplattform (Global):
  • Flertabellsarv kan representera olika typer av kurser (t.ex. OnlineCourse, InPersonCourse, Workshop). Onlinekurser kan ha attribut som 'video_url' och 'duration', medan kurser på plats kan ha attribut som 'location' och 'schedule', och ärva gemensamma attribut som 'title' och 'description' från en bas-Course-modell. Detta är användbart i olika utbildningssystem globalt som erbjuder varierande leveransmetoder.
  • Abstrakta basklasser kan lägga till gemensamma fält som 'difficulty_level' och 'language' för att säkerställa konsekvens över alla kurser.

Slutsats

Django-modellarv är ett kraftfullt verktyg för att bygga välstrukturerade och underhållbara databasscheman. Genom att förstå skillnaderna mellan abstrakta basklasser och flertabellsarv kan du välja rätt tillvägagångssätt för ditt specifika användningsfall. Kom ihåg att överväga avvägningarna mellan återanvändning av kod, databaskomplexitet och prestanda-overhead när du fattar ditt beslut. Att följa de bästa praxis som beskrivs i denna artikel hjälper dig att skapa effektiva och skalbara Django-applikationer.